home *** CD-ROM | disk | FTP | other *** search
/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / x2ftp / msdos / theory / strateg3 / code_ai.txt < prev    next >
Encoding:
Text File  |  1994-12-12  |  6.1 KB  |  199 lines
  1. <Edited by x2ftp admin>
  2.  
  3. Shortly after Tim Triemstra and I posted articles discussing strategy
  4. game AI to rec.games.programmer, a Danish student by the name of
  5. Peer Sommerlund (peso@diku.dk) posted an article in which he
  6. outlined an object-based "methodology" for implementing an AI system
  7. which combined my ideas with Tim's.  I was impressed by the effort
  8. which Peer put into his article and wrote to him, suggesting that I
  9. would like to see his posting, Tim's postings and my "essay" appear
  10. together at x2ftp.oulu.fi.  When Peer expressed his approval of the
  11. idea, I contacted Tim, who was also keen to be a part of the venture.
  12.  
  13. --- Andrew
  14.  
  15. e-mail addresses:
  16. Peer Sommerlund: peso@diku.dk
  17. Tim Triemstra: empath@umcc.umich.edu
  18.  
  19. Jouni: Yes, we are very interested in computer opponent AI and want
  20. more theory, ideas, implementations, source code, anything =-)
  21.  
  22. --------------------(Peer Sommerlund's article)--------------------
  23. Newsgroups: rec.games.programmer
  24. From: peso@diku.dk (Peer Sommerlund)
  25. Subject: Re: AI programming (ala Civ, Moo, etc.)
  26. Date: Fri, 2 Dec 1994 17:03:22 GMT
  27.  
  28. andrew@cs.uct.ac.za (Andrew Luppnow) writes:
  29.  
  30. > empath@umcc.umcc.umich.edu (Tim Triemstra) writes:
  31. >[Summary of a computer-player-AI technique based on "situations."]
  32. >
  33. >Tim's post reminded me of a little "essay" on the topic of
  34. >strategy-game AI which I wrote last year.  I just thought I'd
  35. >dredge it up and see what you all think of the ideas I was
  36. >toying with back then.  Hope the splurge below doesn't bore you
  37. >too much!   ;-)
  38.  
  39. [Andrew defines a hieracial system of situations]
  40.  
  41. I think the two ideas match nicely. Tim has described a nice way of building
  42. prototypes for your game, Andrew has described a way to build larger systems
  43. (ie. ISS wargames).
  44.  
  45. I like Tim's idea, especially the point about "the one that fits the current
  46. situation best". This way you could get your game up running fast, and
  47. refine it as you find weaknesses. You may even make your rule-database
  48. user-modifiable!
  49.  
  50. A system that can be gradually expaned is very usefull. You might even make
  51. a system that can start at 1 level then later expand  by building a higher
  52. level function. And another, etc..
  53.  
  54. Let's call Tim's expansions for "horizontal expansion"
  55. and Andrew's for "vertical expansion"
  56.  
  57. So, you should define two classes:
  58. class action
  59. class actor
  60.  
  61. Action is what your actors do.
  62.  
  63. Let's take an example
  64. Actor Tank1, Tank2, Boss;
  65.  
  66. Actor gets goal from higher level, send goals to lower levels, gets progress
  67. >from lower levels, sends progress to higher levels
  68.  
  69. Action =
  70.   "move this direction", etc..
  71.  
  72. Actor loop :
  73.     get goal
  74.     decide strategy
  75.     deploy strategy
  76.     evaluate strategy
  77.     report to superior
  78.  
  79. deploy strategy:
  80.     send goal to lower level
  81.     get report from lower level
  82.  
  83. Ok, now all this should be running concurrently!
  84.  
  85. Actor loop:
  86.     switch
  87.         case new goal: redesign strategy
  88.         case report available: evaluate strategy
  89.  
  90. redesign strategy:
  91.     get goal
  92.     evaluate current strategy
  93.     if strategy needs change
  94.         change strategy
  95.         send new goals to lower levels
  96.  
  97. evaluate strategy:
  98.     see if current reports matches with current goal,
  99.     can I optimize the situation by sending new goals to subordinates?
  100.     if the situation has changed since last time superior was notified,
  101.     tell him.
  102.  
  103. Right. A concurrent Actor should know the following things:
  104.     - last reports send to superior
  105.     - last goals send to subordinates
  106.     - current goal recieved from superior
  107.     - current reports recieved from subordinates
  108. .. and the interesting part:
  109.     - how to match goals and reports
  110.  
  111. You may want to use Tim's excelent method here: A collection of
  112. situations (S), a distance measuerement (D) between situations, an
  113. action (A) connected to each situation.
  114.  
  115. You find the S that is closest to the current situation S0 by minimizing
  116. D(S,S0). Then you apply the matching A. If you're clever, you'll sort the
  117. situations some way, and your search will be much quicker, but this is not
  118. neccesary in the first attempts to get things up running.
  119.  
  120. so, "how to match goals and reports": Your situation has the following
  121. attributes: (last_goal_recieved, last_goals_send, last_reports_recieved,
  122. last_report_send) ... perhaps a few more: time, your location, etc.
  123.  
  124. Just to be able to differ between goals going up and down, lets use this
  125. wording:
  126.  
  127.             superior
  128.     A            | Goal
  129.     | Summary        V 
  130.                me
  131.     A            | Command
  132.     | Report        V
  133.           subordinate
  134.  
  135.  
  136. .. well, lots of talk. Back to the example:
  137.  
  138.      T1
  139.         E
  140.  
  141.     T2
  142.  
  143.  
  144. This is a simple 2D game. Let's say each tank has a cannon that only points
  145. forwards, a tank turns slowly, so an escape strategy is to move a lot. The
  146. bullets take some time to hit target, so you can move forward, wait untill
  147. enemy points at you, then move back, etc. Also, the tank cannot turn, and
  148. move, at the same time.
  149.  
  150. Some technical details:
  151. There is 32 directions your tank can face.
  152. Your tank is a circle with diameter 8,
  153. tank speed 0.1 unit/frame,
  154. cannon reload: 100 frames
  155.  
  156. the bullet has diameter 1.
  157. bullet speed 1 unit/frame,
  158. bullet range: unlimited, 
  159.  
  160. An overall strategy (the boss) may be "surround": place a tank on opposite
  161. sides, let one duge the cannon, while the other shoots him in the back.
  162.  
  163. Lets give the boss the following rules:
  164.     "split": if tanks are close, separate them
  165.     "surround": try to move the tanks such that ennemy is surrounded.
  166.     "prepare duge": don't move the tank so close to the enemy that
  167.     it cannot move away before it gets hit.
  168. leading to this set of commands:
  169.     "move here, duge"
  170.     "move here, kill"
  171.  
  172. Let equip each tank with the following rules:
  173.     "survive", 9: if ennemy is targeted on you, move 1-2 squares
  174.     "kill", 5: if goal is "kill" rotate to target enemy, shoot
  175.     "move", 4: if goal is "move here" rotate to face target position,
  176.     move
  177.     "duge", 6: if you are off your target position, and duging, wait
  178.     until enemy cannon points at you.
  179. commands:
  180.     "forward"
  181.     "backwards"
  182.     "wait" (don't move)
  183.     "turn left"
  184.     "turn right"
  185.     "shoot"
  186. summary:
  187.     "current position"
  188.  
  189. Remember to put priorites on rules, you don't want the order of the rules
  190. decide which rule should be executed.
  191.  
  192. regards,
  193. -Peer
  194. -- 
  195. Peer Sommerlund \ Groenjordskollegiet v2512 \ 2300 Koebenhavn S \ Denmark
  196.         \ E-mail: peso@diku.dk
  197.  
  198. -------------------------------------------------------------------
  199.